Telecommunications-network usage is constantly expanding, and with the addition of a new application comes challenges to the way in which customers requests are handled. Existing or legacy programs must meet these challenges in short order with minimal changes.
With the introduction of VoIP/VOP (“Voice over Internet Protocol” or more generally “Voice Over Protocol,” which includes ATM, etc.), cable providers desire to provide telecommunications-type services over a CATV network. It is desirous to route calls through switches run by Local Exchange Carriers (LECs). The LECs must be able to connect and handle these calls seamlessly, as well as bill appropriately for these calls. That is, if telephony services are being offered to customers by a first party (such as a CATV provider), but technologically provided by a telecommunications carrier, the customer orders will need to be processed by the telecommunications carrier but billed to the customer by the CATV provider. With portability, much of the information associated with a telephone number can change, therefore it is important that this information be kept current. Thus, when a subscriber requests service through a cable partner, the cable partner must submit an order to the LEC to make changes.
Many barriers are present today that would make it difficult implementing the model discussed above. For example, when the LEC's market and the cable partner's market overlap, an “In-territory” problem occurs because the end-customer is in the market territories of both the CATV provider and telecommunications company. Absent the present invention, the legacy system would try to handle such a customer as if it were the LECs customer, and thereby try to bill the end-customer as a customer of the LEC (instead of the third-party's customer). Alternatively, it would reject a service order by the cable partner for this customer because it would treat such a record as a duplicate. Another illustrative problem exists in handling data and data types that differ from those expected, for example, accepting alpha-numeric characters in data fields where traditionally only numeric data have been used or adding new data to be processed.
Overhauling or replacing legacy systems so that these problems could be remedied require significant programming effort, data reformatting, time, resources, and expense. With the rapid changes in the industry, the need exists for service order entry systems to be flexible, and able to adapt quickly and effortlessly to change.